Agile outsourcing – outsourcing development to groups using Agile methods – is an up-and-coming topic. (Hey, if people can mashup selling pet food and the Web, why not outsourcing and Agile methods?) Like everything else, outsourcing is not a cure-all. Indeed, there are enough pitfalls (IMHO) in Agile outsourcing that over the long term it will be seen as just one more tool in the business toolbox (possibly an insignificant tool).
When you engineer a solution, you can (short of technological breakthroughs) pick at most two of: Good, Fast, and Cheap. Let's take a look at each of these design axises as it regards Agile outsourcing.
Good – the quality of the resulting product – is generally enhanced by Agile methods, as the emphasis on testing (esp. automated testing) help drastically reduce one large category of defects, while the continuous customer involvements helps ensure that what is built actually meets the customer's needs. My informal, unscientific survey of the top Google results for 'agile outsourcing' in the past hour indicates that "continuous customer involvement" does not seem to be wanted by those using what they call Agile outsourcing, as the Agile outsourcing teams seem to want to drop contacts down to once every 2 weeks or so. Without continuous involvement by your customer, you run the risk of building something they *don't* want.
Fast – how quickly you can develop the necessary result – would also seem impeded by the lack of continuous customer involvement in Agile outsourcing, as rework will be required when what is built is not what was wanted (while building what the customer wants is enforced by continuous customer contact).
Cheap – cost savings from reduced resources and/or reduced price for the resources – would also seem undercut to me by not having continuous customer involvement (the apparent standard developing for Agile outsourcing projects) and/or by forcing a greater proportion than normal of a client's resources devoted to keeping Development and the client group in sync.
For me, if you don't have continuous customer contact – if software is thrown over the wall every couple of weeks – then what is now passing for Agile outsourcing is just ordinary iterative development spread across geographic regions. Compared to BDUF, it is still better. But calling it Agile outsourcing is a misnomer, as you have removed:
Business people and developers must work together daily throughout the project.
from the Agile Manifesto (actually "Principles of the Agile Manifesto"...)
Requirements are usually the hardest part of any project to get right, whether you are talking about software engineering, building a house, designing a traffic pattern, et.al. Continuous customer contact ("work together daily") helps a lot with getting requirements correct, as the feedback loop is tighter, thereby promoting a more stable development process (where stable means that mostly forward progress is made, rather than multiple incidents of rework interspersed with progress).
Forgoing continuous customer contact, as most Agile outsourcing businesses appear to be doing now, forgoes the advantage of quicker development by getting the requirements right as needed. Alternatively, I think that attempts to apply true Agile practices to outsourcing will likely result in projects that have no advantages over local Agile-based projects.
P.S. An exception to this rule would be development of a system where your development team has no experience with the infrastructure; a WS-* interface when a team has been doing only client-server and normal Web-page applications, for example.
Be careful generalizing about agile methods. Scrum, for example, includes no technical practices.
Re:Agile Techniques Have Different Practices
Mark Leighton Fisher on 2007-06-22T17:07:13
Yes, I should have been more careful in what I had written. I have the "Extreme Programming Core Practices" and "Principles Behind the Agile Manifesto" posted in front of me, both of which support what I tried to make my main point, that the need for accurate and precise requirements communication will wipe out the gains from many attempts at Agile Outsourcing as it seems to practiced today. My bad on including TDD as a practice common to all Agile methodologies.
